A computer program typically includes many functions/methods that are executed while the computer program is running. The functions are executed by one or more processors in conjunction with at least one memory. The memory is used to store information for the functions, and such memory may include processor registers, cache memory, one or more stacks, main memory, some combination thereof, and so forth. A stack, for example, is usually employed to store information for multiple functions in a linear (e.g., temporal) manner.
FIG. 1 is a conventional stack 101 that illustrates an exemplary unwinding 105 thereof for handling an exception. As shown, stack 101 relates to multiple functions A, B, C . . . L, M, and N. As each function is called or as one function transitions to another function, information for a function 103 is added to the stack. An example of such information is a frame or a call frame.
For example, information for function A 103(A) is at the bottom (or at least the lowest illustrated portion) of stack 101. When function B is called, information for function B 103(B) is added onto stack 101. Similarly, information for function C 103(C) . . . information for function L 103(L), information for function M 103(M), and information for function N 103(N) are gradually added to the stack.
Each of information for a function 103 may include such information as ongoing variable(s), stack pointer(s), instruction pointer(s), data in the registers of processor(s) that represents at least part of a current state of the processor(s), some combination thereof, and so forth. This information may be useful when an exception occurs.
Although modem programming entails significant debugging and testing, every imaginable event cannot be fully predicted. Such unexpected events can be accommodated and/or hidden from user view through exception handling routines/procedures. However, every function does not usually include error handling information. To reach a function that includes error handling information, stack 101 is unwound until information for a function 103 relates to a function that can handle unexpected events. In other words, information entries 103 of stack 101 are traced back through, walked back up, etc. during a typical error handling procedure.
To that end, assuming function N cannot handle the experienced exception, stack unwinding 105 NM is used to unwind stack 101 from a state appropriate for function N to a state appropriate for function M. If function M also does not possess appropriate error handling information, stack unwinding 105ML is used to unwind stack 101 from a state appropriate for function M to a state appropriate for function L. Stack 101 is thusly unwound until information for a function 103 that relates to a function that can handle the unexpected event is reached.
FIG. 2 is a conventional compiled file 201 in a static format. After a file is written by a programmer using an editor to produce source code, a compiler is applied to the source code to produce object code in a machine language that is processor-consumable (e.g., a program executable file). The compiler is afforded the opportunity to consider all of the source code (possibly over multiple iterations of compiling) to “optimize” the organization of the object code while considering all objects, references, functions, error handling capabilities, and so forth. The compiler can thus produce a file 201 that is neatly organized in a predictable, static format.
An exemplary organization for file 201 includes first and second portions: code 203 and an unwind table or tables 205. Code 203 organizes individual code sections for functions A-N in an ordered fashion. Specifically, code 203 illustrates code for function A, code for function B, code for function C . . . code for function L, code for function M, and code for function N.
Unwind table 205 is organized into three parts: unwind information 207, exception handling (EH) information 209, and code address (CA)-to-pointer information 211. Each of these three parts 207, 209, and 211 are subdivided into sections that are directed to particular functions. Specifically, each part 207, 209, and 211 illustrates sections for function N, for function M . . . . Although not explicitly illustrated, each part 207, 209, and 211 may have sections for all functions A, B, C . . . L, M, and N. In certain described implementations, unwind information 207 corresponds to so-called “r data”, exception handling information 209 corresponds to so-called “x data”, and code address (CA)-to-pointer information 211 corresponds to so-called “p data”.
For CA-to-pointer information 211, each section that is directed to a particular respective function includes one or more of at least three entries: a start address, a final address, and an unwind pointer. The start address and the final address relate to the addresses of the code for the respective function in code 203. These addresses may be relocatable virtual (RVA) addresses that are offsets from the beginning of code 203 and/or file 201. The unwind pointer is a reference that points to a section of unwind information 207 for the respective function. Thus, CA-to-pointer information 211 may imply that information from the address range of the coding to an unwind pointer for a function is provided, may imply that information for a mapping from instruction pointer (IP) addresses associated with a function to an unwind pointer thereof is provided, may imply that both information types are provided, and so forth.
As illustrated for unwind information 207, each section that is directed to a particular respective function includes at least two entries: an unwinding description and an exception handling (EH) pointer. The unwinding description describes how the stack can be unwound from the particular respective function back to the previous function. For example, an unwinding description of unwind information 207 for function N describes how to effectuate stack unwinding 105NM for stack 101. Each exception handling pointer for a respective function is a reference that points to a section of exception handling information 209 for that respective function.
For exception handling information 209, each section (if present) includes exception handling information for a particular respective function. The exception handling information includes (native) exception handling tables or similar that explains how to handle one or more exceptions that have been experienced.
Illustrated file 201, and unwind table 205 thereof, can be effectively navigated quickly by an operating system (OS) when an exception occurs because it is cleanly and orderly organized. Consequently, standard computer science algorithms targeted to searching for and/or locating desired information may be employed.
Unfortunately, code that is compiled on-the-fly and/or in ad hoc situations cannot be so easily organized logically and orderly in prescribed manners with predictable, static formats. Accordingly, there is a need for schemes and techniques that facilitate exception handling in a dynamic environment.